データマネジメントにおけるメタデータ管理についてまとめてみた

どーも、データアナリティクス事業本部コンサルティングチームのsutoです。

データマネジメントに関する知識を体系立ててまとめた「DMBOK」（ここでは第２版であるDMBOK2）には、広範なデータマネジメントの概念として11個の知識領域が定義されています。

その中に「メタデータ」の管理に関する記述があります。増え続けるデータの種類と量の全体像を把握しやすくする目的として、

• 業務用語とその利用法に関する組織の理解を提供する
• 様々なソースのメタデータを収集し統合する
• メタデータにアクセスするための標準的な方法を提供する
• メタデータの品質とセキュリティを確保する

ことをゴールとしてメタデータの管理を考えることの必要性を謳っています。

じゃあ具体的に、『自分たちの組織の組織と照らし合わせてどんな方針で考えて整備していけばよいのだろう』という疑問に対して、「とりあえずメタデータ管理できるツールを入れればいい」とか「すべてのデータにメタデータの付与と管理をしていかなければならい」というようなアクションを起こしても、チームや組織の体制に合ってなかったり運用が続かず形骸化してしまいます。

本記事で概要レベルではありますが、メタデータ管理の方針について私なりにポイントとなる内容をまとめてみました。

メタデータ管理を行うためのマネジメントをどう設計していくかの要件を洗い出すきっかけとなればいいなと思っています。

なぜメタデータ管理をするのか

データ利活用の拡大に伴う課題

多くの企業がデータ分析基盤を利用してデータ利活用を進めるにあたり、データ収集・分析のために連携するシステムや組織の規模が拡大していきます。それに伴って組織間のデータ連携も活発になり、あらたな分析結果に基づく付加価値が生まれてくると思います。

しかし、分析業務の組織拡大、データの種類や量の増加によって以下のような課題が発生してきます。

データサイエンティストが抱く課題

• 欲しいデータがどこにあるか見つからない
  • データの検索とアクセスに時間と労力が浪費される
  • データレイクがデータスワンプに変わる
• どこの部署に頼めば目的のデータが手に入るのかわからない
  • 社内で使用するビジネス用語とデータが結びつかない
• そもそも、システムに格納されている情報（テーブル名やカラム名）だけではもらったデータの持つ意味がわからない
  • 部署間で不足している知識をキャプチャする方法がない

データエンジニアが抱く課題

• データを管理している部署がバラバラであり、問い合わせを受けても連携するデータの調査に時間がかかる
  • 「ダークデータ」の構造や多様性がわかりにくい
• データ定義書のメンテナンスが大変で整理が追いつかず、品質の良いデータを渡すことができない
  • 来歴、品質、信頼性を評価するのが難しい

このことから、人間がデータの持つ意味を理解しやすくする「データを説明するためのデータ」つまりメタデータの必要性が増すことになります。

メタデータがないとデータ分析って進まないの？

この問いかけに対する回答を一言でいうと「ノー」となります。（が、後に「イエス」と言いたくなる可能性は出てきます）

• データベースのテーブル等と違い、ミッションクリティカルなデータではない
• ほとんどのメンバーがシステム内のデータ構造を理解していれば、そもそもメタデータの必要性が低い

上記のように、メタデータはあくまでシステムを運用する人間が組織内にどのようなデータがあるのかを素早く知るための付加情報だということを念頭に置いておきましょう。

ですが、小規模のうちは大丈夫ですが、規模が大きくなると後々管理が大変になることが容易に想像できます。

よってデータ利活用商務の規模が小さい段階から「メタデータをどう管理するか」について構想を練っておくことは有効です。

データカタログツールってすぐに導入すべき？

上述した課題に対処し、データを発見しやすく、品質や信頼性の保持をしやすくするためにメタデータを管理する「データカタログツール」が注目されるようになってきました。

しかし、以下の観点からツール導入でメタデータ管理でやりたいことや面倒なことががすぐに解決できるわけではありません。

• いきなりデータカタログツールを導入してデータベースと連携したとしても、検索して得られる情報が最初から揃っているわけではないし、ビジネス効率に即座に効果が出づらい
  • そもそもデータベース側（ソース側）にメタデータを付与していない、または付与できるメタデータが少ない
  • リネージ情報でデータソース間の変遷は解るが、データマネジメントの観点におけるデータ間のつながり（このデータはどのシステムで使われているのか、どの部署が管理主管なのか、など）は自ら設計して運用していくことが必要
  • データカタログツールは、あくまでデータ分析サイクルのスピード向上のためのツールなので、データソース数や連携組織が多くなり、管理が煩雑になり始めるタイミングと規模で導入することで効果が出る
  • データカタログツールの製品価格やコストについても決して安くない

よって、

• ツールの有無に関わらずメタデータ管理からデータ利活用推進につなげるため、運用方法を整理しておいた方が良い
  • データセット、データリネージの基本情報の他に、ラベル付（Tag名、Bisiness Glossary、ドメインなど）で整理したいメタデータ項目の設計を考える（以下は項目例）
    • システムID
    • 業務システム名
    • 部署名
    • データ保持期間
    • センシティブなデータの有無
    • データオーナー
    • その他（利用上の注意・制約事項）
    • etc
    • ※組織内のすべての要素をメタデータ化するのではなく、「どんな項目でデータ検索できると嬉しいか」「どんな項目が付随していればもっとデータの意味がわかりやすくなるか」を考えて選定すると良い
  • 連携するシステム（データ量）とチームの拡大に伴い、メタデータを集約するための業務ワークフローを確立する

上記のような意識づけを持って運用を続けられれば、ツール導入しても「作業が形骸化してツールのための予算と工数を垂れ流すだけになってしまった」という事態を防ぎやすくなると思います。

データカタログツールの一部を紹介

• 有償ライセンスが必要なサードパーティ製ツール
  • Tableau Catalog
  • Infomaticaのデータカタログ機能
  • Atlan

• クラウドのマネージドサービス
  • Azure Data Catalog
  • AWS Datazone（2023年1月時点ではComing soon）
  • Google Data Catalog

• 無償OSSツール
  • Datahub
  • Openmetadata

メタデータの種類

メタデータは次の3種類に分けることができます。

メタデータの種類	内容	項目の主な例
テクニカルメタデータ	ITにおけるメタデータ	データセット （スキーマ、テーブル、カラム、データ型、キーなど）、 データリネージ、 （ETLジョブなどのデータの変遷、変換方式など）、 BIツールのプロジェクト名やダッシュボード名 etc
ビジネスメタデータ	業務に関するメタデータ	業務システム名、 データベース内のデータ管理者、 システムの管理部署名、 業務におけるデータのセキュリティレベル、 上記を表すラベル付用の情報（タグ、ビジネス用語） etc
オペレーショナルメタデータ	システムを運用する過程で作られるメタデータ	バッチやジョブの実行履歴や実行スケジュール etc

• 基本的にDB、DWH、データレイクなどに保存しているデータソースの情報となる「データセット」と、AirflowのdagやDBtのマニフェストファイルなどから読み取るETLジョブやワークフローの情報である「データリネージ」を取り扱う。

• サーバー側に入れる情報ではないが、業務システムごとのデータの全体像を把握するための「業務システム名」「システムID」「管轄する部署名」「センシティブなデータかを表すフラグ」といったビジネスメタデータを追加で整備していく

• これは素早いデータ検索と意味の理解を促進するために組織ごとに設計が必要で、タグやBisiness Glossary（ビジネス用語）の領域で作り込んでいく意識が必要です。

メタデータ管理にあたってフェーズごとに検討すべき方針

今回は超おおまかに2つのフェーズで考えました。

初期段階

データソースの量やデータ分析業務に関わる組織規模も小さい段階。

ツール導入有りきで始める前に、まずは「データ検索において何をキーワードにしたいか」「どんなカテゴリ名があるとデータを辿りやすいか」を検討する

システム観点

• テーブル表を作成でき、複数ユーザーが同時編集かつバージョン管理も容易なアプリケーション（Wiki、Googleスプレッドシート、Excel、Notionなど）でメタデータ管理表（構造化データを例にするとテーブル定義書が該当）を作成・管理し、付随するメタデータとして管理したい項目も同時に整理する
  • 情報更新などの運用は各データソース管理側で品質を保てるようにする
  • 日々の業務サイクルのなかでメタデータ管理の運用に慣れ、形骸化しないように運用ルールを整理する

マネジメント観点

• テクニカルメタデータ（スキーマ、テーブル、カラム）のそれぞれの単位で項目を整理する
• ビジネスメタデータとして管理すべき項目を選定し整理する
• 日々の業務サイクルのなかでメタデータ管理の運用に慣れ、情報の最新化作業が形骸化しないように運用ルールを整理する

連携規模が多くなってきたら

連携部署の増加、テーブル数の増加に伴い、データカタログツール導入によるメタデータの収集・集約を行い、ツール上でデータ信頼性の管理ができるような体制を検討する

システム観点

• データカタログツールの導入を検討：
  • どのツールでも、導入後は以下の運用が発生する
    • ツールへのメタデータ取り込み用ジョブの作り込み
    • ツールのインフラの管理や各データソースとのコネクション経路の設計
    • ツールのログインユーザー（ユーザーグループ）ごとのパーミッション設計
  • （2023年時点）データカタログツール開発の競争は激しくなっているので、ツール選定の際は、複数の製品をPoCで比較してみることを勧める
    • まずは「データカタログツール」で出来ること、使い勝手を実際に触りながら確認することが重要。無償のデモ機や体験版を公開している製品も多いので試してみるとよい
    • 途中で別ベンダのデータカタログツールに移行したいと思っても、データカタログツールにはマイグレーションを支援するような機能がついているものはほぼ無いため

マネジメント観点

• メタデータ管理における組織体制の整備：
  • データ利活用プロジェクトの規模によって、以下の役割一覧を参考に体制を考える
  • データガバナンスオフィサー：
    • メタデータ管理を含むデータ利活用プロジェクトにおける全体責任を持つ
    • 各種運用ルール、方針策定や見直しにおける最終承認者
  • データスチュワード：
    • メタデータ管理を含むデータ利活用プロジェクトを主導する
    • メタデータの集約と品質の維持において音頭を取り、各データオーナーとの連携、業務の運用フロー確立を行う役割
    • データカタログツール上では「Administrator」に相当する
  • データオーナー／ビジネスオーナー：
    • 各システムのデータソースの管理者
    • システムにおけるDB（データセット）やETLジョブ（データリネージ）などのリソースを管理しており、テーブル定義書の品質維持を行う役割
    • データカタログツール上では「カタログの編集権限を持つユーザー」に相当する
  • データアナリスト／データサイエンティスト：
    • データ利活用において、実際に分析・可視化の作業を担当する
    • ビジネス側の幅広い知識を備え、利用データ要件や分析要件を整理して実務を担当するので、整えたメタデータ管理のルールや運用環境に対して実際に使ってフィードバックする立場
    • データカタログツール上では「一般ユーザー」に相当する

最後に

データカタログツールの導入やしっかりとした体制作りをしたとしても、データソースの多様化や開発速度による連携が追いつかなくなる、また組織体制そのものの変更による影響などで、本来ミッションクリティカルではないメタデータ管理業務が後回しになり形骸化する可能性は十分あります。

この懸念は「データカタログツールを導入」や「メタデータ管理のための厳密な体制とルールを確立」しただけで、大逆転ホームランのごとく全て解決することはありません。

「メタデータ管理」という仕事の運用を継続していくには組織の敷ける体制の規模を考慮して負荷の少ない運用業務フローをメンバーで考えながら組み立てていくことが必要です。

まずは各システム管理者やデータアナリストとコミュニケーションしながらメタデータ管理業務を行うことの意味を理解してもらい、日々の業務の1つとして定着させられるよう意識づけをしてもらうことから始めましょう。その最初の手段としてメタデータ管理表の作成とメンテナンスを継続する方法でよいですし、うまくいっているならその方法を継続するだけで何ら問題ないと思います。（もちろん使うツールも既知のツールであるExcel、WIki、Notion、Markdownでも別に問題ではない。かける学習コストもスモールスタートの方がとっつきやすいはず）

ツール導入は、効率が低下してタスクの自動化、データ規模増大によるガバナンスやセキュリティ等の細かいパーミッションの実装の必要性などの需要が大きくなったタイミングでも遅くないと思います。